In order to transport web pages over secured and encrypted channels, web servers and browsers may pass HTTP traffic over SSL/TLS-type connections (also known as HTTPS or Secure HTTP).
The most common visual indication that a web page is being transported over HTTPS is the “lock” icon found in many browsers. When the lock is closed, a user understand that a received page was transported over a secure channel, and when the lock is open, they understand that it was transported insecurely. In addition, in most browsers, double-clicking on the lock icon, (or the first part of the browser's address bar), may result in the display of a SSL/TLS certificate for the sending server, which indicates the authenticity of the sending side.
A problem with the HTTPS implementation, is that the indicators only apply to what is currently being viewed (the current page). If a user visits a web page and the page contains a web form (e.g. some text fields, and a submit button), the user has no way of knowing if the return submission of the form itself will be using HTTPS or clear HTTP. Presently, there is no “secure form” indicator in HTML and contemporary browsers.
This means that when a user is at a log-in page of a web application, even if the login page itself was received over SSL, the user may have no way of knowing if the login itself will be secured prior to its submission. This deficiency is found in many types of sensitive forms such as Credit-Card/Checkout forms, etc. This lack of a secure-submission indicator becomes an even bigger problem in modern Web 2.0/AJAX applications where a user may be looking at a page received securely and the page will spawn a new frame including a form which is overlaid on top of the original page. This new layer is not the actual page previously indicated as being secure, so the user has no knowledge about its origin or if the return submission itself will be over HTTPS or not.